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Executive summary 


Can distributed ledger 
technology (DLT) help financial 
institutions optimise the real- 
time liquidity of their Nostro 
accounts and reduce the 
significant operational costs 
associated with reconciliation? 


This was the question on the 
industry's mind when SWIFT — 
together with 34 leading global 
transaction banks — kicked off 

a proof of concept (PoC) to use 
DLT to provide real-time visibility 
of Nostro accounts. 


Based on the business and technical 
requirements validated by the participating 
banks, SWIFT developed a DLT solution 
whereby the Nostro Account owner and its 
Servicer share a private confidential ledger 
recording transactions related to their Nostro 
account. 


The solution leveraged ISO 20022 standards 
and gpi innovations — including the unique 
end-to-end transaction reference (UETR) — 
and integrates the intraday liquidity standards 
developed in line with the SWIFT intraday 
liquidity standard rulebook. 


Throughout the PoC, the participating banks 
tested 34 use cases impacting Nostro 
account balances and went through a liquidity 
testing phase. Using the developed Nostro 
application and a supporting back office 
simulation tool, they collectively assessed 
whether and how Nostro reconciliation and 
liquidity optimization could be supported and 
improved compared to current processes. 


The PoC was built within the SWIFT DLT 
sandbox environment — a use case agnostic 
DLT platform which enables experimentation 
and collaboration between SWIFT and its 
community. The sandbox is a first step 
towards a SWIFT DLT platform, combining 
leading distributed ledger technology, 
Hyperledger Fabric 1.0, with SWIFT assets to 
deliver a unique offering tailored to the needs 
of the financial industry. This solution leverages 
SWIFT’s comprehensive governance and 
identification framework complemented by 
extensive controls guaranteeing confidentiality 
and security. 
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Results 


With 34 banks participating in the initiative 
and 28 banks actively testing using their 

node deployed in the SWIFT DLT sandbox, 
the initiative was one of the most extensive 
blockchain proofs of concept and Hyperledger 
implementations executed in the industry so 
far, in terms of participant engagement and of 
the scale of infrastructure deployed. 


Based on extensive testing, the participating 
banks found that the Nostro DLT application, 
when combined with the underlying ISO 
20022 data model, delivered the business 
functionalities and data richness required 

to support automated real-time liquidity 
monitoring and reconciliation. This was made 
possible thanks to a systematic real-time 
confirmation of each account entry and use of 
the UETR. 


The PoC demonstrated the huge progress 
DLT has made with regards to data 
confidentiality, governance, security, and the 
identification framework, evidencing that the 
emergent technology, combined with SWIFT 
assets, does now provide the necessary 
foundation for building financial applications. 
However, it also showed that further progress 
is needed on the DLT technology itself before 
it is ready to support applications in large- 
scale mission-critical global infrastructures. For 
example, while 528 channels were required 

in the PoC to ensure Nostro accounts would 
only be stored on the nodes of their account 
servicers and owners, to productise the 
solution, more than 100,000 channels would 
need to be defined, covering all existing 
Nostro relationships, presenting significant 
operational challenges. It is however clear that 
it is no longer a question of whether DLT will 
reach maturity but rather when it will reach 
maturity. 


Key findings 


While the results are encouraging, testing also 
highlighted the need for a set of pre-requisites 
for such a solution to deliver the expected 
benefits and be adopted by the industry: 


1. There is a need for all Nostro Account 
Servicers to migrate from batch to real- 
time liquidity reporting and processing. 
Today, 44% of cross border payments 
exchanged over SWIFT generate a 
real-time confirmation of debit or credit 
(MT900/910)'. 


2. While the DLT application could provide a 
platform to share the information, there is 
significant work and investment required 
by all banks to upgrade their back office 
applications to feed the platform with 
real-time updates. The success of any 
solution will be dependent upon deep 
integration with back office systems 
using APIs. These implementation costs 
could be significantly lowered should ISO 
20022 standards be adopted first for the 
payments themselves. This would ease 
integration as a common data model 
providing the required level of granularity 
for Nostro. 


3. A value proposition for each market 
segment catering for different levels of 
sophistication, automation of operations 
and past investments is key to ensure 
industry-wide adoption and coexistence, 
hereby delivering maximum value. 


The benefits for the larger clearing banks 
are less clear since their dependency 

on external Nostro Servicer providers is 
reduced overall when compared to mid- 
tier banks. Larger banks typically manage 
their key currencies internally and 

have already invested heavily in highly 
optimised liquidity and reconciliation 
tools. 


1 (SWIFTWatch — FIN traffic — 2017) 


2 httos://www.swift.com/news-events/press-releases/swift-and-csd-community-advance-blockchain-for-post-trade 


Also, additional intelligence built in 

to the ledger and deeper integration 
with existing inter-related processes, 
such as Nostro liquidity management, 
reconciliation, exception management 
or regulatory reporting is needed to fully 
capture the benefits of a DLT solution. 


4. Unique identification of each entry is 
the cornerstone of any liquidity and 
reconciliation solution. The re-use of the 
gpi UETR, leveraging SWIFT’s central 
payments tracker for this purpose is 
an obvious choice. To cover all Nostro 
account movements, its usage must be 
extended to identify key message types 
such as FX and securities transactions 
that potentially do not settle through a 
payment message. 


Next steps 


While real-time Nostro reconciliation and 
liquidity remains a strategic priority to reduce 
operational costs and comply with new 
regulatory frameworks in some jurisdictions, 
the PoC revealed that the pre-requisites will 
have to be met before banks can enjoy the 
full benefits from switching to a DLT process. 
Moreover, considering the high impact to 
banks and payments systems operations, 
SWIFT, together with the participating banks, 
concluded that the timing might not be right 
for a community investment in this area. 
Current interest rates and other priorities, 
especially in countries where regulators have 
not yet published any intraday reporting 
guidelines, will have an impact on future 
development. 


Therefore, as a next step, SWIFT will continue 
working together with its community on the 
following initiatives to address the identified 
pre-requisites before working on the 
oroductisation of the Nostro application itself: 


1. SWIFT will continue encouraging its 
community to migrate towards real- 
time liquidity reporting and processing, 
and will be monitoring both progress 
in that direction, and any regulatory 
development in this area; 
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2. SWIFT will start an ISO 20022 
consultation with its community to assess 
a timeline and a migration approach 
towards ISO 20022 as a means to 
reduce the community implementation 
cost; and 


3. As part of the gpi roadmap, extension 
of usage of UETR to other payment 
types and beyond payments will 
be considered, in order to provide 
transaction identification for all nostro 
movements. 


It is a strategic priority for SWIFT to work 
with new technologies like DLT. SWIFT will 
be continuing its research and development 
efforts to ensure that over time, SWIFT 
members can leverage their existing SWIFT 
infrastructure and SWIFTNet connectivity 

to benefit from blockchain services, offered 
by SWIFT or third parties, on a secure and 
trusted platform, connected to 11,000 
members globally. 


In particular, SWIFT’s 2018 plans for DLT 
include: 


1. Continue developing DLT usage with 
its community through other PoCs 
deployed in the SWIFT DLT sandbox and 
participating in industry consortia, such 
as Hyperledger and the CSD working 
group’ to name two; 


2. Work towards evolving our platform to 
complement it with DLT capabilities, 
developing the value proposition and 
product offering; 


3. Continue reviewing and assessing 
the evolution of various blockchain 
technologies in line with financial industry 
requirements; and 


Actively promote the re-use of ISO 20022 
in a DLT and API context. For example, 
through the ISO technical committee 307 
on blockchain standardisation. 


Introduction - Industry 
background 


Improving operational efficiency 
and reducing transactional 
costs for international payments 
has become one of the key 
priorities for banks in their 
response to: increasing 
customers’ expectations and 
regulatory requirements, whilst 
maintaining their competitive 
position. 


On average, 34% of the cost 
of an international payment 

is related to Nostro trapped 
liquidity caused by the absence 
of real-time data to optimise 
intraday liquity management. 
Meanwhile, 9% of the cost 

is linked to investigations or 
exceptions mainly driven by a 
lack of standardisation in the 
end-to-end payment’s process, 
and by the related Nostro 
account reconciliation’. 
Overfunding of Nostro accounts or 
alternatively excessive use of credit lines 
particularly regarding payments settled in a 
different time zone is mainly driven by the lack 


of visibility and predictability on intraday in and 
out flows. 


A real-time information mechanism at 
transactional level would not only reduce costs 
by enabling liquidity optimisation; it would 

also enhance banks’ ability to provide a better 
service to their customers by enabling earlier 
release of payments whilst reducing recalls 
and liquidity risks. 


3 Global Payments Report 2016, McKinsey 
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Many banks have initiated projects to 
implement real-time liquidity management 
that will deliver substantial financial benefits 
beyond their compliance with new regulatory 
requirements. These include financial savings 
such as lower funding costs and a reduction 
of related risks, especially during times of 
higher market volatility. 


To achieve this, banks need the ability to 
monitor their intraday liquidity usage through 
a real-time confirmation of each entry on their 
various Nostro accounts, as well as improving 
their intraday forecasting through systematic 
early identification of incoming movements. 


Real-time Nostro reconciliation is an integral 
part of this process, which requires timely 
matching of all movements on the account. It 
should enable banks to improve operational 
efficiency leading to a reduction in the cost 
related to open entries, including an end of 
day overdrawn balance or potential charges 
and interests. 


To remain competitive, back office cost for international 
payment should drop by 90 to 95% 


Figure 1 - Cost per international payment transaction 


USD 25-35 


Payment operations 


Nostro-Vostro 
liquidity 


Claims and treasury -90 - 95% 


operations 


Compliance 


USD 1-2 


FX costs 


Network 
managment (2%) 





Overhead (3%) 


2016 Objective, needed to 


remain competitive 


Source: McKinsey & Company, Global Payments 2016: Strong Fundamentals Despite Uncertain Times 


What were the main issues 
we aimed to address? 


Data gaps 


Real-time Nostro liquidity and 
reconciliation management 
require banks to collect 
transaction-by-transaction debit 
and credit confirmations in 
real-time. 


Despite the new intraday 
liquidity rules implemented in 
some jurisdictions and derived 
from the recommendations 
expressed by the Basel 
Committee on Banking 
Supervision (BCBS 248) 
advocating for improvements 
in intra-day reporting industry 
oractice, there are still 
important data gaps. 


Results of the last market consultation on 
intraday liquidity carried out at Sibos Geneva 
in October 2016, reveals that whilst progress 
has been made, the industry is still facing data 
challenges: 


— Joo few transactions reported on a real- 
time basis (18% of responses). 

— Lack of timeliness of the reporting (19% 
of responses). 

— Lack of granularity in the information 
provided including the required time 
stamps (21% of responses). 

— Limited business practice for the usage 
of credit notifications in support of 
intraday liquidity (15% of responses). 


Many large account servicers have invested 
heavily in their real-time reporting capabilities 
for top currencies. However, the majority is 
still facing challenges to provide the real-time 
feeds requested by their customers for some 
transaction types. Any intraday projection from 
these account owners will be based 

on their internal forecasting system and 

not on the timed confirmations from their 
account servicers. This will potentially have an 
impact on their ability to calculate their real- 
time balance. Transactions leading to such 
issues will typically include book transfers with 
no underlying payment instruction, or cash 
entries related to transactions managed by 
other business lines such as payments related 
to corporate actions. 


Figure 2 - Simplified current Nostro flows 


MT 103 ref ABC 














MT 202 ref DEF MT 103 ref GHI 
Bank A Bank B 
Nostro Account Owner MT 103 ref KLN Nostro Account Servicer 
Shadow r Real 
Nostro Account Nostro Account 
of Bank A MT 300 - FX DEAL confirmation ref XYZ of Bank A 
-1000 $ -1000$ | +1000$ 
reconciled? (ABC) (GHI) 
[MT 900, 910, 942 -> Missing COVERAGE, TIMESTAMP ] 
- 2000 $ <-@ ------------ - 2000$ | +1500$ 
reconciled? (DEF) | (KLN) 
MT 940, 950 -50$ 
Match? charges 
etc 


Reconciliation with end of day statement 


Line 60a -> opening balance 
Line 61 -> debit entry (- 1000 USD) (ref ABC) 
Line 61 -> debit entry (- 2000 USD) (ref DEF) 





Line 61 -> credit entry (+1000 USD) (ref GHI) 
Line 61 -> credit entry (+ 1500 USD) (ref KLN) 
Line 61 -> debit entry (- 50 USD charges) 


Line 61 -> credit entry (+ 1000 USD) (XYZ) 
Line 62a -> closing booked balance 
Line 64 -> closing available balance 
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The lack of data centralisation and 
integration 


A number of institutions have not yet 
centralised the management of their Nostro 
accounts. Legal entities within the same group 
may use different payment hubs distributed 
around the world to send their instructions and 
receive confirmation messages from both their 
internal and external clearing service providers. 


Treasury and reconciliation systems have, 

in most cases, not been integrated across 
regions and currencies. Being able to rely 

on a single source of aggregated data is a 
desired objective of larger institutions but there 
remains a data standardization and distribution 
challenge in order to build a view of real-time 
positions both at firm-wide and entity-wide 
levels for key currencies. The complexity and 
cost related to such projects represent major 
obstacles to their implementation. 


Exceptions and investigations 


Exceptions and investigations have a multiplier 
effect on the overall payment cost. Issues 
related to pending transactions on Nostro 
accounts (payments and receipts that have 
not yet settled or cash receipts that have not 
been pre-advised) which are reported through 
the end of day statement are only identified 
towards the end of the day. 


From a funding perspective, especially close 
to the cut-off for a specific currency, it is a key 
need for banks to identify potential pending 
transactions or unexpected ones. 


Investigations related to post-settlement or 
to unmatched items (either unreconciled or 
unconfirmed entries) also result in a highly 
manual resolution process. 


Treasury operations in particular, invoicing 

of both regular and exceptional payments 
processing fees based on bilateral price 
agreement leads to a complex monthly 
reconciliation process resulting in a number of 
expensive claims managed manually. 


Basel Committee on Banking Supervision 248 
(BCBS 248) — Monitoring tools for intraday liquidity 
management 


How does the PoC fit into 
the gpi initiative 


1. Today 


SWIFT gpi brings to banks’ corporate 
customers same day use of funds, 
transparency, traceability, and unaltered 
transmission of remittance data for their 
international payments. The improved visibility 
of payment status is also expected to reduce 
the volume of investigations. It already 
provides the foundational layer thanks to the 
use by all goi member banks of a Unique 
End-to-end Transaction Reference (UETR) 

to link the real-time status on the payments 
with the entry status on the related Nostro 
Account - potentially leading to an impact on 
the intraday balances. 


2. Tomorrow 


Building on the successful launch of gpi in 
early 2017 and the rapid adoption by the 
community, SWIFT will release three new gpi 
services towards the latter part of 2018, to be 
adopted by all gpi banks: the cover service, 
extended tracking of gpi payments, and the 
Stop & Recall service; further consolidating gpi 
as the new normal for correspondent banking. 


As from November 2018 gpi will enhance 
banks liquidity management function through 
extended tracking of key payment types 
allowing banks and their customers to identify 
their incoming payments flows as soon as 
they have been initiated. 


Additionally, as part of the gpi innovation 
stream, SWIFT conducted its first gpi Industry 
Challenge in 2017 to encourage FinTech 
companies to build overlay services leveraging 
the gpi platform, solving incremental 
challenges faced by corporate treasurers. 
During the early part of 2018, the two winning 
FinTechs will work with SWIFT on a proof of 
value based on the two winning ideas. 
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3. Future 


This proof of concept is part of the fostering 
innovation stream of gpi, focussed on the 
exploration of new technology develooments 
to enhance correspondent banking 

services and operational processes. Going 
forward SWIFT will continue to evaluate 

new technologies through gpi, and that will 
ultimately benefit the entire community - not 
just gpi banks. 





“We were pleased to participate in 
this PoC. Once again it confirmed the 
potential that DLT has for different 
facets of the international payments 
process. We look forward to continue 
working with SWIFT on the GPI and 
related DLT efforts.” 


Julio Faura, 
Head of Blockchain, R&D, Santander 


Objectives and scope for the 
proof of concept 


End-to-End Nostro account 
entries workflow (see figure 3) 


Business objectives 


The aim of the PoC is to 
demonstrate whether a real 
time DLT solution could help 
resolve the identified issues that 
include: 


There is a need to demonstrate that the 
distributed ledger solution provides real time 
visibility of relevant information for both the 
Account Owner and the Account Servicing 
institutions related to: 


— The status of a transaction entry in the 
Nostro Account as well as of any related 
— Less than optimal funding account entries (e.g. charges); 
positions across Nostro 
accounts due to lack of 
real-time visibility of the 
account's entries, and 
monitoring of the related 
intraday expected and 


available balances; 


The status of the underlying payment 
processing that could have an impact on 
the entry status in the Nostro account 
(e.g. rejected payments or cancellations) 
or that could delay the booking process 
(e.g. payments under investigation or on 
hold); 


— The impact on the related Nostro 
account intraday balance (expected and/ 
or available balance). 


— Operational savings through 
increased efficiency of 
Nostro reconciliation. 


Figure 3 - DLT PoC End-to-End entries lifecycle 


Account Owner 


Debtor 


Payment initiation MT 103 











Payments initiated by a debtor are created on 
the ledger by Account Owner (AO) or 
Account Servicer (AS 
AS) API call to Ledger 
2 All information related to an entry created by AO 2 
or AS is visible to the other party in real-time 


Ə Entries created by the AO will need to be confirmed by the AS before they are booked on the ledger. 
Entries can also be rejected. If an exception / investigation has been started on 1 entry, an exception 
entry be created on the ledger for information 


©} Entries are confirmed by the AS 


QO Distributed ledger will record all entries created with their respective initial status and all changes 
to their status. It will derive the respective update intraday balance accordingly (e.g. pending entries 
will be added to the expected booked entries will be added to the available balance) 


Account Servicer 


—e——> (a9 —0o ___— 
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All entries such as charges related to the 
same transaction (e.g. customer payment) 
shall be identifiable through the use of a 
common reference in order to support the 
reconciliation process. 


The life cycle of entries in the DLT Nostro 
account should be directly synchronized with 
the payment process because any event in the 
process could have an impact on the related 
entry. Therefore, the DLT solution should 

cater for the creation of exceptions entries to 
identify in near real-time the underlying reason 
for pending entries. 


It should also enable the account owner to 
identify whether it could delay the confirmation 
process and have an impact on the intraday 
account balance. 


The end-to-end account entries workflow 
concept (see figure 3) was tested during 
the PoC for a representative number of 
transaction types and use cases. 


Creditor 


Confirmation of credit 





Shared ledger 


Transaction entry creation S103 


@ Transaction entry confirmation 






Exception entry creation 





@ Transaction entry creation 


Audit trail 


The distributed ledger needs to provide 
non-repudiation evidence for each entry 

on the account. Used in a mutualised way as 
a trusted data source for liquidity and liquidity 
risk management, or even for regulatory 
reporting purposes. A full audit trail being 
automatically created would provide evidence 
of the liquidity transfer in case of dispute or 
provide trusted underlying information in case 
of a regulatory investigation. 


An important condition to support an audit 
trail of the entry in the ledger is the availability 
of a unique end-to-end transaction reference 
(UETR) for each entry in the shared ledger 
provided by either the Account Owner or the 


Account Servicer, depending on the use case. 


4 Please refer to httos://www.swift.com/our-solutions/ 
global-financial-messaging/payments-cash- 
management/intraday-liquidity-reporting 
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Common standards 


A key success factor in an industry solution 
for real-time Nostro liquidity and reconciliation 
is the development of common standards 
created from a set of common business rules 
and technical specifications. 


The data model of the PoC is based on the 
ISO 20022 standard and is aligned with 

the existing and newly developed gpi best 
practices and standards for payments and 
SWIFT Intraday Liquidity standard for Intraday 
Nostro reporting’. 


A standardised input to the shared ledger 
defined the data set and the format provided 
to participants to create, confirm or reject an 
entry. The standard includes a common time 
stamping model that distinguishes the creation 
time of an entry from its booking time or its 
value time. 





“ANZ has been encouraged by this 
initiative, not just in the progress 
made in extending and testing a DLT 
solution for Nostro Reconciliation, but 
also by the scale of the collaboration, 
which evidences the industry’s 
desire to go beyond incremental 
improvements and explore radical 
changes enabled by new technology. 
Proofs of concept like these are 
good examples of how maturing 
innovations like DLT can, and should, 
be guided by use cases with clear 
links to customer and business 
outcomes. ANZ looks forward to its 
continuing involvement in furthering 
causes that benefit the broader 
community.” 


Nigel Dobson, 
Banking Services Domain Lead, Digital 
Banking, ANZ 


Business scope 


Ten business dimensions (see 
figure 4) were identified for the 
develooment of a DLT based 
real-time Nostro liquidity and 
reconciliation concept model. 
While any production solution 
would need to address those 
ten dimensions, the scope of 
the PoC was limited to the 

key dimensions required to 
demonstrate the value of a 
transaction life cycle whilst 
ensuring the highest volume 
coverage. 

Thirty-four standard business use cases were 
specified and developed to cover the selected 


dimensions and used as the reference for 
testing by all participants. 


A detailed list of objective criteria was agreed 
in relation to the identified business promises 
in scope for the PoC (see table 1 in Annex). 
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Figure 4 - Business dimensions scope 


Business 


i i In scope for the PoC Not in scope for the PoC 
dimensions 





Roles — Account Owner institution — Tracker 
— Account Servicing Institution 
— Shared ledger with smart contract 


Transaction entry 





Charge entries — OUR charges — Charges billed on other Nostro 
— Processing charges (CAT2) — Rebate on processing charges 
— Charges on payments exceptions (e.g. 
repair) 








Sub-entries 
Account entry = a 
= OOKG 
status - Rejected 
Balanced type 
FX — FX indication in MT103 


Role in payment 
chain 





Back / Forward — Forward value entry — Back value entry 
entry 


Payment status 





Technical objectives 


SWIFT have been analysing 
and testing, for some time now, 
the potential application of 
distributed ledger technology 

in the financial industry. In April 
2016, SWIFT conducted an 
in-depth assessment of DLT 
that determined the technology 
was not mature enough to 

fulfil the requirements of the 
financial community. While this 
conclusion still holds true today, 
SWIFT has seen a number of 
major advancements in the 
past year addressing the critical 
requirements necessary for the 
technology to achieve 
industry-wide adoption. 
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From a technology point of view, the objective 
of this Proof of Concept was threefold: 


1. To assess DLT in a “many-to-many” 
setting, addressing a real business use 
case to draw lessons for larger scale 
implementations of the technology and 
assess benefits over other architectures. 


2. To assess whether these new 
technology advancements, combined 
with SWIFT assets, allow the fulfilment 
of key industry requirements such as 
governance, security and data privacy. 


3. To check the current level of maturity 
against the requirement for a production 
grade application, and as a mission 
critical global infrastructure. 





“The PoC provided validation 

that mid-tier banks will likely see 
substantial benefits in liquidity 
management. However, the ability 
of DLT to reach its maximum, 
transformative potential for the 
financial industry is fully dependent 
upon its capacity for seamless 
integration and interoperability with 
existing bank infrastructures.” 


Vivek Kohli, 
Director, Emerging Payment Technology 
Head, BNY Mellon Treasury Services 


Using the SWIFT DLT 
sandbox to meet the PoC 
technical requirements 


The Nostro proof of concept 
was built within the SWIFT DLT 
sandbox environment. The 
sandbox environment is a use 
case agnostic DLI platform 
providing the foundations for 
building proof of concepts and 
experimenting together, with 
the SWIFT community. It is a 
first step towards a potential 
SWIFT DLT platform, combining 
leading distributed ledger 
technology with SWIFT assets 
to deliver a unique offering 
tailored to the needs of the 
financial industry. 

Hyperledger Fabric 1.0 was selected as 

the underlying technology for the SWIFT 


DLT sandbox for its support of the following 
features: 


— tis a private permissioned ledger 
solution which is able to strictly control 
access to the ledger(s). 


—  |t supports selective data distribution, 
allowing not only secure data access but 
also physical data storage to relevant 
nodes only. 


— it Supports native integration with a 
certification authority, allowing for all 
access keys used for parties identification 
and transaction signing to be certified, 
providing trust in key authenticity and in 
the identity of parties. 


— it provides a smart contract platform 
— chaincode in Hyperledger Fabric 
terminology - that can be leveraged to 
implement business logic and workflows. 


12 


Next to those technical reasons, Hyperledger 
is an open source initiative driven primarily 

by the needs of the financial industry. SWIFT, 
as well as a number of the participants to 
the proof-of-concept, being Hyperledger 
members, made the latter a good fit. 


Scalability 





Reliability 





Security and 
cyber defence 


ie 


The SWIFT DLT sandbox has been built 

to meet six of the eight industry requirements 
identified by SWIFT in its previous paper and 
illustrated above in figure 5. The below section 
summarizes for each one of them: 


How this requirement is translated for 
Nostro reconciliation use case. 


— How this requirement is being met in 
the proof of concept using SWIFT DLT 
sandbox. 





Figure 5 - 
Key industry 
requirements 
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Strong governance 


KO% 





Data controls 


Compliance 
with regulatory 
requirements 





Standardisation 





Identity 
framework 


Compliance with regulatory requirements and 
security are the last two industry requirements 
which were identified as part of SWIFT’s 
position paper. The Proof of concept does 
not focus on those two aspects, primarily 
because we believe that the technology is too 
new to undergo a security assessment and 
the regulatory developments remain in their 
infancy. 


Development of the PoC started on Hyperledger 
Fabric 1.0 alpha. Migration to Hyperledger Fabric 1.0.1 
was performed following its availability. 


Strong governance 





Requirement 


Access to the solution must 
be restricted to the relevant 
institutions while updates and 
consultation of a particular 
account must only be allowed 
to the actual account owner 
or servicer. Furthermore, 
distinction shall be made 
between the privileges of an 
Nostro Account Owner and 
of its Account Servicer. For 
example, only the Account 
Servicer must be able to 
effectively confirm a debit 

or a credit on the account 
once it has been successfully 
processed. 





DLT sandbox implementation 


Two types of users are defined — SWIFT 

and participants — with a different set of 
privileges. SWIFT users are responsible for the 
administrative and management function (e.g. 
user management and provisioning, creation 
of genesis block, smart contract provisioning) 
while the participants users have access to 
the actual business functionalities. 


Participant membership is managed through 
a Closed User Group (CUG) while a Role 
Based Access Control (RBAC) service defines 
business roles for participants in the CUG. 


Two roles have been defined - Account Owner 
and Servicer — and the combination of the 
participant identity together with the role 
assigned determines what actions are allowed. 
For example, only the Account Servicer may 
confirm a pending payment to effectively 

debit or credit the account. Both CUG and 
RBAC functionalities are implemented through 
chaincodes on the ledger. 


The strict segregation between SWIFT and 
business participants together with the 

CUG and RBAC functionalities deliver a 
comprehensive governance framework where 
roles and responsibilities are clearly defined 
and strictly enforced. 
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Data controls 





Requirement 


Access to the data about 

a particular Nostro/Vostro 
account must be granted only 
to the actual Account Owner 
and Account Servicer. Next to 
securing access to the data, 
data must also be physically 
stored only on the nodes of the 
relevant parties — the Account 
Owner and its servicer — rather 
than disseminated through 

the entire network. Selective 
data distribution reduces the 
risk of malevolent access to 
the data as even the strongest 
encryption algorithms may not 
pass the test of time. 








DLT sandbox implementation 


To ensure confidentiality of the Nostro 
accounts, the DLT sandbox relies on the 
following controls: 


1. Access to a particular account is limited 
to its Owner and to its servicer. The 
Account Owner and Account Servicer 
roles define the type of actions that can 
be performed on the account. 


2. Information about a particular Nostro 
account is only stored (and is only 
accessible) on the nodes of the Account 
Owner and of the Account Servicer, 
and on the ordering service nodes. 

This is enforced using the “channel” 
functionality of Hyperledger Fabric 1.0. 
A channel is being defined for each 
bilateral business relationship; effectively 
creating a dedicated ledger storing all 
information related to the accounts those 
two institutions hold with each other. 
This generates a significant number of 
channels. If there are n participants, 

the theoretical maximum is n*(n-1)/2 
channels if all participants have a 
business relationship with each other. 


3. As part of the consensus process, a 
transaction on the Nostro account is 
only seen and approved by the Account 
Owner and of the Account Servicer, 
and checked by the ordering service 
operated by SWIFT. 


Further to these 3 controls, encryption of 

the data was not implemented as part of the 
PoC due to timing constraints, but would be 
considered for any production implementation. 
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“Accessing the DLT sandbox 
environment, we were able to 
engage with clients to showcase the 
positive effects on intraday liquidity 
management.” 


Andreas Hauser, 

Senior Product Manager for Intraday Liquidity 
Management, Cash Management, Deutsche 
Bank 


Standardisation 





Requirement 


Existing MT and ISO 20022 
standards providing real- 

time entry status for Nostro 
accounts. Io foster adoption 
of any real-time solutions, and 
minimize its implementation 
cost, it is a key requirement 
to leverage newly developed 
industry practices. To adapt 
them to a paradigm where 
information is shared between 
transaction parties rather 
than only exchanged through 
messages. 
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DLT sandbox implementation 


The Nostro reconciliation proof of concept 
was built leveraging existing newly developed 
market practices and existing ISO message 
standards. In particular, the data model 

used to store all transactions on Nostro 
accounts is based on the ISO 20022 
BankToCustomerStatement (camt.0593). 

ISO 20022 was selected over the MT 
equivalent (MT950) for its increased richness 
and granularity. Data quality is an essential 
requirement to be able to improve transaction 
reconciliation - one of the key business 
objectives of the proof of concept. 


Next to the data model, the business 
workflows supporting all 34 use cases 
covered as part of the proof of concept were 
implemented using chaincode based on the 
ISO 20022 standards and in line with the 
SWIFT intraday liquidity standard rulebook. 


Thanks to the data model and the workflow 
being inspired by ISO 20022, API calls 

that were created to support the various 
interactions with the ledger were also defined 
using ISO 20022 data elements. 


Although APIs were developed, they were 
not exposed to participants for this proof of 
concept because all interactions were done 
through a web interface. APIs allow for deep 
integration with back office applications that 
are becoming more ISO 20022 compatible. 
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Identity framework 





Requirement 


Transactions posted on a 
Nostro account are very 
sensitive in nature and it is 
therefore critical to ensure 

a strong identity framework 
where parties are identified 
through a legal identifier such 
as the Business Identifier 
Code (BIC) or the Legal Entity 
Identifier (LEI). A trusted third 
party is required to register 
participants and certify 
authenticity of security keys. 
The central registration authority 
ensures a much stronger 
identity framework compared 
to public blockchain models 
where identities are pseudo- 
anonymized and keys self- 
certified. 
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DLT sandbox implementation 


The DLT sandbox relies on a two level 
participant identification scheme whereby: 


Participants are identified and addressed 
through a legal identifier. The BIC was 
used as part of the proof of concept. 
Membership to the CUG is defined at the 
participant level. 


Keys used by participants to access/ 
sign transactions are certified by a SWIFT 
controlled Certification Authority, through 
the issuance of Certificates. Those keys 
are tied to the participant through their 
distinguished name (DN) that contains 
the business identifier code identifying 
participant ownership for each of the 
keys. 


Note as part of the PoC, all keys used 

are stored on disk. For a production 
implementation, hardware security modules 
(HSM) that offer suitable protection against 
key theft would be considered. 





“As a global leader in financial 
innovation, RBC is working 
collaboratively across industry 

to explore the use of emerging 
technologies in a variety of 
applications. We are excited 

about the potential of Blockchain 
technologies. While we are in the 
early days, this proof of concept has 
demonstrated how this technology 
could lead to a number of benefits, 
such as faster reconciliation, 
simplified processes and increased 
security.” 


Lisa Lansdowne-Higgins, 
VP Business Deposits & Treasury Solutions 
RBC Royal Bank 


Reliability 





Requirement 


With DLT technology rapidly 
evolving the main objective of 
the PoC as far as reliability is 
concerned was to: 


1. Assess the maturity and 
stability of the technology 
from a reliability point of 
view; and 


2. Understand the impact 
of running a DLT based 
solution for a mission critical 
application such as Nostro 
reconciliation, taking into 
account the significant 
architectural changes 
inherent with DLT solutions 
to meet the needs of the 
financial industry. 
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DLT sandbox implementation 


To cater for the data privacy, strong 
identification and scalability requirements 

of the financial industry, the architecture of 
distributed ledger solutions had to adapt 
significantly. Emerging technologies are 
moving from fully distributed architecture 

to hybrid models whereby some of the 
components are distributed, others are 
centralized. Hyperledger Fabric is not different 
in that regard and was reflected in the DLT 
sandbox. While the participant nodes storing 
information on the Nostro accounts are fully 
distributed, they rely on a number of “central” 
components operated by SWIFT. 


In particular, the following infrastructure is 
operated by SWIFT: 


— A set of nodes in charge of the user and 
role management. Those nodes have 
no access to data related to Nostro 
accounts. 


— A central certification authority in charge 
of issuing certificates and of maintaining 
a certificate revocation list. 


An ordering service in charge of ordering 
transactions, within a channel, into 
blocks. 


To ensure a resilient setup, resiliency for the 
participant nodes as well as for the SWIFT 
operated components was foreseen. For 
example, the ordering service was operated 
as a cluster of 4 nodes. 


The resiliency of each participant relies on 
other nodes from the same participants, on 
the nodes of its Accounts Servicers/Owners 
for the accounts it owns/services, or on the 
ordering service. 





17 


Scalability 





Requirement 


Scalability needs are very 
dependent on the use case. 
For Nostro reconciliation 
each financial entity would 
need to have a bi-lateral 
relationship (channel) with 
every correspondent they have 
an account with; and within 
each relationship there may 
well be multiple ledgers each 
representing a single Nostro 
account. 


Secondly, there is a focus on 
ensuring that DLT can provide 
real-time visibility on the Nostro 
accounts and that as such, 
consensus is achieved within 
seconds. The latency needs to 
remain stable as the number 
of Nostro/ Vostro relationship 
increases quadratically when 
the number of corresponds 
grow. 
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DLT sandbox implementation 


To make sure that consensus is reached 
within a few seconds for each transaction, 
irrespective of participant location, the 
consensus algorithm parameters of the 
SWIFT DLT sandbox were fine-tuned so that 
consensus would take place every 2 seconds. 


Further to that aspect, the DLT sandbox 
environment was scaled to support the 
number of participants (84) and of the related 
number of channels (528). 





“SWIFT’s gpi Nostro PoC using DLT 
is focused on driving back office 
efficiencies. From our perspective, 
the constraints of such a DLT 
solution are mostly two-fold: firstly 
a limited number of counterparts 
participating in the system could 
impact the efficiency because 
banks would be obliged to maintain 
two different tools to manage 

two different positions. Secondly, 
integration of the technology with 
internal systems, and also from an 
accounting perspective, is essential 
to success. A DLI based solution 
should take integration costs with 
legacy applications into consideration 
to avoid any duplication of costs.” 


UniCredit Spa 


Testing strategy 


SWIFT engaged with global 
transaction banks to test the 
model concept application. 


Timeline Summary 


2017 


Formal 
start 


Requirement specification 
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In PoC enviroment 2018 
Live with Live with Interim Final 
6 banks 28 banks report report 


Participant requirement review 


Development on v1.0 Alpha Migration v1.0 GA 


In total, 34 banks contributed to the proof of 
concept segmented in two groups working 
independently from each other. 


The initial six financial institutions formed the 
founding group who worked with SWIFT to 
explore and define the standards, data model, 
business and functional specifications, that 
resulted in the creation of the concept model. 


The founding group was the first to test the 
application and to provide feedback. The 
participating banks also provided a number 
of change requests to improve the user's 
experience of the application, of which, a 
certain number were implemented prior to 
the start of the final phase of testing with the 
validation group in September 2017. 


The validation group of 28 financial institutions 
were tasked with executing the same set of 
tests to provide independent conclusions on 
the enhanced solution. 


The size of the group also provided an 
opportunity to see how the distributed ledger 
technology scaled with the increase in the 
number of Nostro relationships. 


Testing group 1 Testing group 2 


Analysis & recommendation 
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Participant validation and 
testing activities 


To validate the proposed 
concept model, banks 
participated in the following 
activities: 


1. Business and technical specifications 
covering the data model, the functional 
and technical scope, were reviewed by 
all participating banks. 


2. Testing was executed using the 
developed proof-of-concept deployed in 
the SWIFT DLT sandbox. In particular: 


Twenty-eight banks performed the 
functional testing against the 34 use 
cases aiming at ensuring the PoC met 
the functional requirement, and to assess 
the completeness of the ISO 20022 data 
model. 


Nine banks performed the liquidity testing 
to assess the impact on the visibility of 
their intraday liquidity positions across 
accounts, and whether potential savings 
could be derived from the proposed 
ledger concept model. 


3. Upon completion of the PoC, strategic 
evaluation workshops were held with 
12 participating banks to gather their 
findings and feedback. 


4. Finally, 17 banks replied to the survey to 
gather qualitative feedback to support 
the quantitative testing results. 


The following section summarises the results 
and findings of those various activities. 
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Validation by participants 


1. 


Participant review of 
business and technical 
specifications 


2. 


28 banks performed 
functional testing 


9 banks performed 
liquidity testing 


3. 


12 individual strategic 
evaluation workshops 
with top global 
transaction banks 


4. 


Participant Survey 
completed by 17 
banks on the qualitative 
findings 


Functional Testing 


The scope of the testing was determined by 
the business dimensions selected for the PoC, 
and focussed on the most representative set 
of industry-wide use cases. 


The objective was not only to validate the ISO 
20022 data model but also to test extensively 
the value of the end-to-end workflow for 
Nostro account’s entries with real-time visibility 
of their status and of the audit trail functionality 
relying on the re-use of the UETR. 


The real-time nature of the solution utilising 
the UETR also meant that automated 
reconciliation of payments against the Nostro 
account entries would result in less enquiries, 
and consequently to a shorter turn-around 
time for enquiries. 


Results from this extensive testing by the 34 
participating banks, confirm that the DLT PoC 
application relying on a standardised rule 
book and leveraging the unique end to end 
transaction reference delivers the expected 
business functionalities and data richness; 
required to support business applications and 
processes in achieving automated real-time 
liquidity monitoring and reconciliation. 


Liquidity Testing 


A subset of participants were asked to 
confirm the impact on the visibility on their 
intraday liquidity positions across accounts 
and whether potential savings could be 
derived from such a shared ledger solution. To 
that end, participants were asked to upload 
obfuscated real transaction data to the DLT 
application covering a period of one to several 
days. This enabled them to compare the as-is 
situation based on current reporting updates 
received from their Account Servicer with a 
simulation based on the uploaded real-time 
reporting provided by the concept model 
application. 


As a baseline, the following metrics were 

used to compare the current liquidity curve 
based on existing debit and credit entries 
confirmations by the Account Servicer with the 
real-time simulated view: 


— Impact on intraday balance position at 
specific time of the day (peak positions). 


— Impact on imbalances between credit/ 
debit entries. 


— Reduction of difference between 
expected balance and interim available 
balance - top peaks in difference and 
elapsed time. 


Results from the participants were 
representative of the current liquidity curves for 
the tested Nostro accounts, and simulation of 
real-time reporting and comparison with as-is 
situation demonstrated a substantial impact 
on all these metrics. 


Key conclusions from the test are as follows: 


— Real-time confirmation for each debit 
and credit entry could result in visibility 
of accurate intraday liquidity curves, and 
an identification of potential imbalances 
between credit and debit entries. 


— The use of systematic real-time 
confirmations would substantially reduce 
the gap between the expected and 
available balance when compared to 
batch reporting. 


From a time zone perspective, collecting 
real-time information close to the cut-off 
would help improve liquidity forecasting, 
identify potential exceptions and enhance 
the management of account funding: 
Participating banks also agreed that 
potential liquidity savings could be 
realised by developing or leveraging 
additional controls, functionalities or 
business intelligence analytics. 
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— Liquidity optimisation could be achieved 
through an automated payment flow 
control based on the real-time position 
avoiding extensive use of credit lines, 
contributing to lower intraday liquidity 
buffers; and 


— Systematic timed data at entry level 
would support a more accurate 
regulatory reporting. 


However the first pre-requisite in order for 

the industry to fully grasp liquidity benefits, 

is for banks to move current liquidity and 
reconciliation processes to real time. There 

is also a need to integrate the data from the 
shared ledger with existing liquidity or treasury 
applications, and with regulatory reporting 
modules. 


Time zone difference issues can only be 
solved with an extension of the payments 
settlement's window and of the bank’s 
operational hours to a full 24 hour period. 


Strategic workshops and 
participant survey results 


Seventeen banks also provided their input to a 
questionnaire distributed after the testing. The 
purpose was to collect structured feedback 
on PoC and its perceived benefits should such 
a solution be productised and implemented at 
the level of the industry. 


Respondents were namely asked to indicate 
the level of importance they associated with 
the capabilities of a DLT based solution 

to process liquidity events and reconcile 
transactions in real time; as applied to eight 
major back office processes within their 
respective banks. 


The chart on the next page represents a 
distribution of the level of importance the 
respondent banks placed on the benefits 
towards each of those processes moving to a 
real-time operating model. 


From an industry-wide perspective, the 
majority of respondents agreed on the 
importance (high or medium rating) of moving 
to real-time liquidity and reconciliation across 
the back office to eliminate inefficiencies. 
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Figure 6 - Level of importance of real-time benefits attributed to liquidity and reconciliation by respondents 


Low 
expected 
benefits 


Real-time account 
management 


12% 


Customer Service - 
Financial Institutions 
customers 


Intraday liquidity 
forecasting 


18% 


Exceptions and 
investigations 
management 


24% 


Customer Service : 
Corporate/retail 
customers 


Treasury 
reconciliation 


35% 


Intraday liquidity 
regulatory reporting 


Accounting 
reconciliation 


0% 10% 20% 


Participants feedback on the value 
of DLT application 


Beyond a full alignment with the results 
already put forward in the liquidity testing 
section, banks provided some key feedback 
on benefits and impact. 


On the benefits side: 


— The size of the institution largely 
determines the level of importance 
given to liquidity reporting capabilities 
offered by a DLT based solution. Mostly 
determines how respondents see the 
inherent value of a real-time DLT based 
Nostro reconciliation service; and 
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Medium 
expected 
benefits 


47% 18% 
53% 


30% 40% 


50% 


— Whilst respondents see value in improved 
customer service towards financial 
institutions, a greater value is placed on 
improvements to back office processes 
and efficiency gains. 


On the impact side respondents felt that: 


— There would be a benefit to explore 
how smart contract technology could 
be leveraged in the delivered solution, 
to lower the cost that would be required 
from each bank to add some intelligence 
to the ledger; 


— There are significant dependencies 
outside of the technology to deliver all the 
promised benefits; and 


12% 


60% 


High 
expected 
benefits 
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35% 


35% 
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— Impact on the various back office 
processes of such a DLT solution would 
be substantial. 


Whilst resoondents were positive on many 
aspects of the technology and related 
benefits both to the bank and industry, 

all acknowledged there are unanswered 
questions and significant challenges to 
adoption. 


It is clear that a value proposition for each 
market segment catering for different levels of 
sophistication, automation of operations and 
past investments is key to ensure industry- 
wide adoption. 


Conclusions 


Based on extensive testing, 

the participating banks found 
that the Nostro DLT application, 
when combined with the 
underlying ISO 20022 data 
model, delivered the business 
functionalities and data richness 
required to support automated 
real-time liquidity monitoring 
and reconciliation. 


The PoC also demonstrated 
the significant progress DLT 
has made with regards to data 
confidentiality, governance, 
security, and identification 
framework, when compared 
with the results of SWIFT’s 
2016 assessment of DLI. 


However, despite encouraging results, there 
are still some gaps that need to be addressed, 
confirming that it is still early days for the latest 
generation of distributed ledger technology to 
be considered mature enough as a basis for a 
global mission critical financial infrastructure. 


In short the conclusions can be divided into 
four main categories: 


1. Adequacy of the DLT based Nostro 
solution as defined by the functional 
requirements. 


2. The value proposition will depend on 
bank’s liquidity management capabilities, 
level of automation and centralisation. 


3. A “one size fits all’ DLT solution will not 
work. 


4. New hybrid DLT architectures bring 
significant progress but it is still early 
days to consider it as a basis for a global 
mission critical financial infrastructure. 


1. Adequacy of the DLT based 
Nostro solution as defined by the 
functional requirements 


Testing of the 34 standard use cases by 

the 34 participating banks and additional 
liquidity testing with a subset of those banks, 
demonstrated that the DLT PoC application 
delivers the expected business functionalities. 


Benefits included real-time event handling, 
transaction status update, a full audit trail and 
visibility of expected and available balances, 
and leveraging the SWIFT gpi UETR, which 

is already being implemented by the SWIFT 


community for payment transactions tracking. 


It also confirmed that the ISO 20022 data 
model and API’s specifically developed for 
this purpose are pre-requisites to deliver 
the required structure and data richness to 


support both real-time liquidity monitoring and 


reconciliation. 


On the reconciliation side, the solution 


enables for real-time simplified account entries 


confirmation with an allocation of charge 
entries to a specific payment, identification of 


pending entries and of potential related issues. 


Extensive testing of the use cases between 
participants concluded that such a solution 
could help achieve real-time automated 
reconciliation, hereby reducing the high costs 
related to manual enquiries and streamlining 
their financial institutions customer’s 
experience. 


On the liquidity side, the DLT based solution 
provides real-time visibility across accounts 
to both the Account Owner and the Account 
Servicer (account’s entries status, of derived 
expected, and available account balances). 
It also delivers the timed data required to 
support regulatory reporting. 
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Additional liquidity testing confirmed that 
banks that have not yet achieved such a level 
of monitoring for their key currencies and 
could leverage a real-time solution to optimise 
their intraday liquidity management, enhance 
their liquidity analytics, and support their 
regulatory reporting. 


Unique identification of each entry is the 
cornerstone of any liquidity and reconciliation 
solution. The re-use of the gpi UETR, 
leveraging SWIFT’s central payments tracker 
for this purpose is an obvious choice. To cover 
all Nostro account movements, its usage must 
be extended to identify key message types 
such as FX and securities transactions that 
potentially do not settle through a payment 
message. 





“Bringing the providers and clients 

of correspondent banking Nostro 
reconciliation together has been the 
main benefit of this DLT initiative. The 
potential to improve standardisation 
as well as speed and transparency 
has been confirmed. This is also 

the centrepiece of gpi and could 

be enhanced even further with the 
migration to ISO 20022.” 


Christian Westerhaus, 
Global Head of Clearing Products, Cash 
Management, Deutsche Bank 
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2. The value of a of DLT solution 
will depend on bank’s liquidity 
management capabilities, level of 


automation and centralisation. a. 


The final value proposition will 
depend on bank’s settlement 
model for their key currencies, 
their individual existing 

model to access intraday 
liquidity data, and their level 
of internal liquidity monitoring 
and management process 
automation. 

Global transaction banks usually rely mostly 
on internal entities for the settlement of their 
payments in key currencies, representing 


the largest share of a bank’s liquidity at a 
group level. In most cases these banks 


have implemented a real-time automated D. 


data capture from the different high value 
payments settlement systems to which they 
are connected. They have built transactional 
databases which are not only leveraged to 
feed in real-time their internal sophisticated 
liquidity tools, but also to provide services 
to their different types of customers (both 
financial institutions and corporates or retail 
customers). 


It is therefore expected that any additional 
liquidity saving or reduction of the operational 
costs related to Nostro entries would be rather 
marginal for these banks. Benefits would 
mainly be delivered to financial institutions 
(typically regional players or Investment firms) 
with a higher dependency on Nostro servicers 
and not having made such an investment. 
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However, some key dependencies have 
been identified to enable banks to grasp the 
benefits of such a solution: 


Additional intelligence and integration 
with existing related processes such 

as Nostro liquidity management, 
reconciliation, exceptions management 
or regulatory reporting would be required. 


Whilst the use of smart contracts for 
this purpose could be envisaged, 

it would come at a potentially high 

cost dependent upon the level of 
customisation required on the top of the 
DLT based solution. 


In addition, feedback from participating 
banks indicate that independently 

from the underlying technology layer, 
any potential industry solution should 
leverage existing SWIFT gpi assets and 
services, such as the central tracker, to 
limit the banks’ required investment. 


Many components of today’s liquidity 
management and reconciliation systems 
are typically based on batch processing, 
and rely on end-of-day events. Real-time 
liquidity management is limited by inter- 
bank and payment systems cut-off times. 


To capture the benefits of a real-time 
solution there is a need for all Nostro 
Account Servicers to migrate from 

batch to real-time liquidity reporting 

and processing. Today, around 44% of 
cross border payments exchanged in the 
correspondent banking over the SWIFT 
network generate a real-time confirmation 
of debit or credit (Message 900/910). 
While the DLT application provides a 
platform to share the information, there 

is tremendous work and investment 
required to achieve this consistently 
across all entry types including those that 
did not generate any payment instruction 
(e.g. book transfers). 
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Independent from the selected 
technology, the success of any solution 
targeting a “many-to-many” use case will 
be dependent upon standard API’s or 
messaging. Implementation costs could 
be potentially lowered should 

ISO 20022 standards be adopted. 


Unique identification of each entry is 

the cornerstone of any liquidity and 
reconciliation solution. The re-use of 
the SWIFT gpi for this purpose for a 
correspondent banking DLT application is 
therefore an obvious choice. To this end 
its usage must be extended not only to 
identify any payment type but also other 
types of entries on the Nostro account 
such as FX transactions that potentially 
did not settle through a payment 
message. 


3. A “one size fits all” DLT solution 
will not work 


The integration of DLT 
technology in the 
correspondent banking space 
can only follow an incremental 
path, avoiding disruption 

and preventing the need for 
large players to subsidise a 
significant part of the industry 
deployment. 


Financial Institutions who have made 
substantial investments in existing real-time 
reporting and messaging will indeed be 
reluctant to duplicate the efforts to integrate 
data feeds into DLT nodes. 


Evidence shows a very large increase in the 
usage of these message types (Message 
900/910) with 130% growth* since 2012 
versus 30% growth* in payment messages. 
(SWIF Twatch - FIN traffic - 2017) 


There is a need for a clear segmentation with 
an implementation model that best integrates 
with existing operations and leverages current 
investments such as the gpi central payments 
tracker to minimize the impact and ensure 
the value of the DLT based elements. For 
these banks, extending the central tracking 
utility to capture these messages (Message 
900, Message 910, Message 545, Message 
547), and making the data available to the 
banks that need it would be less impactful 
than implementing a new vertical solution 

in addition to their existing messaging 
capabilities. 


Any solution at the level of the industry would 
have to leverage existing banks’ capabilities 
and allow for an evolution of their internal 
systems. Additional intelligence would need 
to be provided to really bring value for other 
processes such as reconciliation, exceptions 
management, and regulatory reporting. 


4. New hybrid DLT architectures 
demonstrate significant progress 
but it is still early days 


Leveraging Hyperledger Fabric 
1.0, the DLT sandbox clearly 
demonstrates significant 
progress of DLT towards 
maturity, especially with 
regards to data confidentiality, 
governance, identification 
framework and scalability. 


The DLT sandbox provides a very strong 
governance framework where access is 
controlled and where roles define what actions 
participants can perform. Selective data 
distribution ensures that data is stored only 
on the peers having a stake in the transaction 
guaranteeing data confidentiality. Participants 
are identified through their BIC and their 

PKI keys are certified by SWIFT certification 
authority ensuring a very strong identity 
framework. Moreover, the Hyperledger Fabric 
1.0 consensus algorithm demonstrated a very 
low latency and promises to support very high 
throughput. 


One must however realize that it is still early 
days for this newer generation of blockchain 
platforms to reach the level of maturity that 

is required to form the basis of a mission 
critical financial infrastructure. These new 
solutions have a very different architecture, 
moving towards a hybrid model where some 
components are distributed and where others 
are centralized and operated by a third party. 
The architectural design brings significant 
advantages as they are tailored for the 
financial industry, and their impact also needs 
to be carefully assessed. 


Via the mechanism of channels, Hyperledger 
Fabric 1.0 provides a framework that ensures 
that data is stored only on the peers having 

a Stake in the transaction guaranteeing data 
confidentiality. However, channels are static 

in nature and while this mechanism proved to 
be adequate for this PoC where the account 
owner and servicer of a Nostro account didn't 
change, it may be more difficult for use cases 
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where parties to a transaction evolve over time 
or where asset ownership changes. Channel 
configuration and management needs to be 
assessed and explored further. 


The data segregation makes the data 
resiliency question more complex to answer. 
Since data is physically segregated to ensure 
data confidentiality, one node can no longer 
independently recover from any node. Instead, 
it will need to rely either on some local 
resiliency setup within its own institution, on its 
counterparty’s nodes or on a central service. 


Another area for investigation is linked to 

the smart contracts versioning. As smart 
contracts need to be installed on each peer 
and instantiated in each and every channel 
rather than deployed only once, it may bring 
new operational challenges in case a smart 
contract update is required to ensure version 
consistency amongst the peers. Next to the 
upgrade process for smart contracts, upgrade 
mechanisms to the underlying data model 
also needs to be considered. Such migration 
could be challenging, as the data is stored 
(chained) forever in the original format, older 
data models need to be supported forever. 
SWIFT will be looking at assessing those 
points in future. 


Hyperledger Fabric 1.0 shows to be 
straightforward to use from a development 
standpoint. The development tools are stable 
which is an important factor to guarantee a 
productive development cycle. Hyperledger 
Fabric 1.0 fully relies on name-value pairs as 
the only supported data structure. This is a 
weak foundation to implement the richness of 
the ISO 20022 data model. 


From an operational standpoint, a number 

of technical incidents clearly indicate that 
production readiness is not yet reached, anda 
number of enhancements in that area are still 
required. Some elementary tooling is missing 
to properly manage an application, like adding 
a node to a channel or tools to prove any 

non repudiation claim which should be an 
independent capability of a DLT framework. 
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Table 1 
Requirement PoC scope 
Transparency: increase visibility of a Demonstrate provision of real time transaction entry status by the shared ledger according to 
transaction entry status and allow for the agreed standard based on input/ action by the Account Owner and Servicing Institutions 
an early identification of an issue that according to the test cases in scope for the PoC. 
could have an impact on the account’s 
position Time stamps are to be provided for each update. 
Real-time visibility of account’s balances Demonstrate that intraday and the end of day balances are derived in real-time by the shared 


ledger and visible to both the Account Owner and Account Servicer based on entry status 
creation, confirmation or rejection as per the defined use cases. 


Reduce the number of manual Demonstrate that the PoC provides the foundational layer to decrease the number of 

investigations related to charges investigations related to the charges entries on the Nostro account thanks to its audit 
trail functionality and identify which would be the required integration or smart contract 
development required to grasp the full value of this benefit. 


Reduce the number of investigations Demonstrate that entry creation on the shared ledger by the Account Owner simultaneously 
related to being Unable to Apply on the with the payment instruction prevents the loss of data through data truncation and that the 
Nostro Account creation or the confirmation of an entry by the Account Servicer based on the UETR will helo 


reduce the number of investigations for the Account Owner related to un-matched entries. 


Accuracy of the values and data derived Demonstrate transaction entry details and value processed through the distributed ledger 

in the shared ledger is consistent with the data input (e.g. CSV file) from participants. Verification by participants 
that entries status and related intraday balance are derived correctly according to the defined 
standard. 

Support of life-cycle transaction Demonstrate that the shared ledger provides a full audit trail of entries lifecycle according to 

concept the defined standards for each standard use cases. 

Intraday liquidity usage curve DLT Graphical User Interface should update in real-time the intraday liquidity curves 


respectively for the expected and the available balances based on each status update to an 
entry on the account with an impact on the balance as per the standard user case. 


Support of intraday liquidity forecasting Establish through the manual testing of the standard use cases the evidence that the solution 
provides a more accurate real-time liquidity forecasting through a systematic use of expected 
entries (notifications) by both the Account Owner and Servicer. 


Intraday liquidity savings Provide the evidence on a number of expected liquidity benefits through a real-time 
monitoring of Nostro Account’s entries and balances. 


A qualitative evaluation of the benefits is done through manual testing of the standard use 
cases, a quantitative liquidity testing is aimed at evaluating the impact on the visibility of 
intraday liquidity position/ curve by testing the “AS IS” and the “FUTURE” scenarios: 


— From atime bucket vision to real-time vision: difference in real-time balances & peaks 

— Identification of imbalances between credit/ debit entries and of opportunities for funding 
optimisation 

— Visibility on credit lines usage 

— Better data for intraday liquidity forecasting. 
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About SWIFT 


SWIFT is a global member-owned 
cooperative and the world’s leading 
provider of secure financial messaging 
services. We provide our community 
with a platform for messaging and 
standards for communicating, and we 
offer products and services to facilitate 
access and integration, identification, 


analysis and financial crime compliance. 


Our messaging platform, products and 
services connect more than 11,000 
banking and securities organisations, 
market infrastructures and corporate 
customers in more than 200 countries 
and territories, enabling them to 
communicate securely and exchange 
standardised financial messages in a 
reliable way. 


As their trusted provider, we facilitate 
global and local financial flows, support 
trade and commerce all around 

the world; we relentlessly pursue 
operational excellence and continually 
seek ways to lower costs, reduce risks 
and eliminate operational inefficiencies. 


Headquartered in Belgium, SWIFT’s 
international governance and oversight 
reinforces the neutral, global character 
of its cooperative structure. SWIFT’s 
global office network ensures an active 
presence in all the major financial 
centres. 


To find out more about SWIFT’s work 
on distributed ledger technologies, 
please contact DLT @swift.com 


For more information, 

visit www.swift.com or follow us on 
twitter.com/swiftcommunit 

and www.linkedin.com/company/switt 
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About SWIFT gpi 


SWIFT gpi has prompted the largest 
change in cross-border payments 
over the last 30 years and Is the 

new standard, combining real-time 
payments tracking with the certainty of 
same-day settlement. As an initiative, 
it engages the global banking industry 
and fintech communities to innovate 

in the area of cross-border payments 
while reducing their back-office costs. 
Since its launch in January 2017, 

gpi has dramatically improved the 
cross-border payments experience 

for corporate treasurers in over 200 
country corridors. Key features of the 
gpi service include enhanced business 
rules and a secure tracking database in 
the cloud accessible via APIs, resulting 
in faster “same day credits” to end 
beneficiaries, transparency of fees, and 
end-to-end tracking of payments in 
real-time. 


Disclaimer 


This report is the final report. 

The views expressed in this report are 
SWIFT’s views and interpretation of 
the results arising out of the PoC and 
do not necessarily reflect all individual 
participating bank's views. 


